home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 6 / QRZ Ham Radio Callsign Database - Volume 6.iso / pc / files / infodata / pckthdrs.txt < prev    next >
Internet Message Format  |  1994-11-27  |  8KB
  1. From owner-tcp-group@ucsd.edu  Sat Oct 16 12:31:11 1993
  2. Errors-To: tcp-group-relay@ucsd.edu
  3. Sender: tcp-group-relay@ucsd.edu
  4. Precedence: List
  5. From: enge@almaden.ibm.com
  6. Message-Id: <199310151857.LAA00647@ucsd.edu>
  7. Date: Fri, 15 Oct 93 11:55:23 PDT
  8. To: TCP-GROUP@ucsd.edu
  9. Subject: Header Standard
  10. News-Software: Usenet 3.1
  11.  
  12. In case anyone wanted it, here is the original header standard!  The
  13. '$:' was used later when bids appeared.
  14.  
  15. Roy, AA4RE
  16.  
  17.  
  18. ****************************************************************
  19.  
  20. R:870114/0819p S:870114/1206p AA4RE-1, Gilroy, CA --  4983/NK6K
  21. R:870113/1606  @:NK6K Redondo Beach, CA #: 4104 O:NK6K   F:145.36/.01
  22.  
  23. Headers - a compromise proposal.
  24. (1/13/87)
  25. Note:  These comments are necessarily terse, to make them easier to
  26. forward.  This proposal is based on input from VE3GYQ, W3IWI,
  27. NK6K, WB6KAJ, and WB6YMH.
  28.  
  29.  
  30. Executive summary.
  31.  
  32. A standard header format is proposed that permits 1) machine
  33. parsable headers,  2) human readability, 3) extendability
  34. 4) standard non-standard information.
  35.  
  36.  
  37. Why we need a standard.
  38.  
  39. There are at least two programs waiting to be written that
  40. require a machine readable header.  One is a subroutine for BBSes
  41. that can find the originating BBS and send a service message
  42. back.  The other is a FWD.TNC file generator that can determine
  43. paths and connectivity by examining passing headers.  There are
  44. more.
  45.  
  46. There is also a desire on the part of sysops to be able to rapidly
  47. scan a message by eye to look for bad routing, loops, dups, and
  48. delays.   This task could be done programatically, but won't be
  49. for some time to come, and will never be performed by simpler
  50. programs on smaller machines.
  51.  
  52.  
  53. Why the current standards are not sufficient.
  54.  
  55. Aside from the Sent and Received times, the R:S: format as
  56. current specified does not provide an easy way to programatically
  57. determine the following pieces of information:  Originating User,
  58. message number.  These items have been stated as necessary by a
  59. number of BBS sysops.
  60.  
  61. The /this/that/ standard does not provide enough visual fidelity
  62. to permit the eyeball scan to take place.  This is the reason
  63. most often cited for the lack of converts to this standard.  The
  64. other shortfall is the lack of ability to add regional
  65. information in a standard way.  Some areas or networks want
  66. additional information such as frequencies and grid, areacode,
  67. airport, or other positional identifiers.  In a fixed field
  68. format where the item is identified by its location, null fields
  69. would abound when handling several optional special items, e.g.
  70. /call/call/city/state/rtime////freq///stime/.
  71.  
  72. As of late, there are at least three different versions of the
  73. /that/that/ "standard", one with an area code field, one with a
  74. separate state field, and one without either.  This of course
  75. invalidates an otherwise acceptable standard due to its
  76. dependence on field order.
  77.  
  78.  
  79. Attributes of an acceptable standard.
  80.  
  81. Based on the stated wishes of developers, the following are the
  82. requirements of a well-formed header:  Each field can be
  83. identified by a program.  Some fields are required.
  84.  
  85. Based on the stated wishes of some Sysops/Users, the requirements
  86. are:  the header is eyeball-readable, the individual sysop can
  87. add information to suit his local needs.
  88.  
  89.  
  90.  
  91. Stated more formally:
  92.  
  93. 1. Meet FCC third party requirements (whatever they are)
  94. 2. Be compatible with existing software (able to be emitted)
  95. 3. Be machine readable (read: easy to parse)
  96. 4. Provide all necessary information
  97. 5. Provide flexibility for optional information
  98. 6. Provide some degree of user friendliness (read: looks nice)
  99.  
  100. Note:  These comments are necessarily terse, to make them easier to
  101. forward.  This proposal is based on input from VE3GYQ, W3IWI,
  102. NK6K, WB6KAJ, and WB6YMH.
  103.  
  104. The proposal.
  105.  
  106. These requirements are not mutually exclusive.  Rather than use
  107. the fixed field/positional style of the /this/that/ standard to
  108. meet the machine readable requirement, a field identifier is
  109. proposed for each field.  Note that the R:S: standard is already
  110. close to this.  The only thing lost over the /this/that/ format
  111. is some efficiency, more characters are sent.  Losses of
  112. efficiency are common when humans are involved.
  113.  
  114.  
  115. Proposed header format (for the machine readable camp):
  116.  
  117. <header line>      ::= <header field> [<header field>...]
  118. <header field>     ::= <field identifier> <field contents>
  119. <field identifier> ::= <field type> ':'
  120. <field type>       ::= any printable ASCII character except ':'
  121. <field  contents>  ::= a string of printable ASCII characters except ':'
  122.  
  123. Rules:
  124. 1.  The  ':'  character  may  only be  used  as  the  termination
  125. character of a field type specifier
  126.  
  127. 2. The minimum items which should be included in ALL headers are:
  128.      a) The callsign of the node relaying the message.
  129.      b) The time the message was received.
  130.  
  131. Items very (very) strongly recommended for all headers:
  132.      a) the message number of the relaying node.
  133.      b) the callsign of the station originating the message.
  134.      c) the location of the node relaying the message.
  135.  
  136.  
  137.  
  138. Optional information:
  139.      a) Additional location information
  140.           1. Grid squares
  141.           2. Area codes
  142.           3. longitude/latitude
  143.      b) Frequency of operation of node
  144.      c) time message was sent by node
  145.      d) Network name
  146.      e) group name
  147.      f) Major maildrop (nearest major node)
  148.  
  149.  
  150.  
  151. Field  Identifiers:  (Note  new  field types may  be  defined  as
  152. required)
  153.  
  154.  
  155. #: message number
  156. @: Node callsign followed by optional location
  157. A: node ALIAS
  158. F: frequency of operation.  If gateway multiple frequencies are
  159.     separated by "/"
  160. G: Grid square of node
  161. L: Long/Lat of node
  162. M: Major node callsign (nearest major relaying node, the APR
  163.    proposal)
  164. N: Group, node, or network name
  165. O: callsign of originating station
  166. P: Telephone Area code of node
  167. R: Time message was received
  168. S: Time message was sent
  169.  
  170.  
  171. While  many  of  the  above fields may  be  deemed  of  value  by
  172. different  people  the following suggested format is  recommended
  173.  
  174. R:861003/0739z @:W1BBS Packet city, KA #:1234 O:W1ABC
  175.  
  176. Note if the timezone letter is not included it should be replaced
  177. with a space to preserve field alignment for visual fidelity.
  178.  
  179. This header line provides the minimum information which is deemed
  180. necessary by large number of SYSOPs, based on current
  181. discussions.
  182.  
  183. The  proposed  header  format allows  much  flexibility  for  the
  184. individual  sysop's without compromising the ability of  software
  185. to extract the needed information.  Following is an example of
  186. different headers which conform to this standard.  Visual
  187. fidelity and machine readability is maintained.
  188.  
  189.  
  190. R:861003/0701z @:KB3UD, East Bangor, Pa, G:FN20jv
  191. R:861003/0641z @:K3RLI Wilkes-Barre, PA F:145.01/145.05
  192. R:861003/0430  @:N2AYY-1 Glens Falls, NY O:W1ABC
  193. R:861002/2040z @:WA1FHB, Marlow NH #:5432
  194. R:861002/1741z @:WB1DSW O:W1ABC S:861002/2039z
  195. R:861002/1523z @:W9ZRX #:8768
  196. R:861001/1240  @:WB6KAJ
  197. R:861001/1836  @:W6AXM-1 M:WB6KAJ O:W1ABC P:714
  198.  
  199. Final Notes:  The above differs from the current R:S: standard in
  200. that the S: field is missing from the first part.  For visual
  201. fidelity to be maintained, all stations must agree to use the
  202. first two fields in that order.  Those wishing to send the S:
  203. field may do so later in the header.  Dropping the S: from the
  204. required fields is based on the premise that the S: field of a
  205. station can be inferred from the R: field of the next station.
  206.  
  207.  
  208. The RLI/MBL format for the minimum required format is:
  209.  
  210. R:$J/$Kz @:$O location #:$M O:$P
  211.  
  212. 'he "z" is replaced by a space if the BBS uses local time.
  213.